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DETAILED ACTION 

Comments Regarding Examination 

1 . Applicant's amendments to independent claims 1,8,15, and 22 to address 
Examiner's comments made in the last Office action, are acknowledged with 
appreciation. Attached to this Office action are proposed amendments to independent 
claims 1,8, 15, 22, and various dependent claims that would provide a proper 
antecedent basis for certain limitations, correct minor informalities and formatting 
issues, maintain consistency between four sets of claims, and clearly indicate timing of 
events. It is noted that the proposed claim amendments are for the sole purpose of 
correcting problems mentioned just above. 

Response to Amendment 

2. Claims 1-5, 7-12, 14-19, 21-26, and 28 remain pending in the application. Claims 
1, 7, 8, 14, 15, 21, 22, and 28 are currently amended. Claims 6, 13, 20, and 27 have 
been canceled. No new claims have been added. 

Response to Arguments 

3. With regard to the Applicant's remarks dated August 21 , 2008: 

regarding the rejection of claim 1 under 35 U.S.C. 103(a) as being unpatentable 
over AAPA in view of Craft, Applicant's arguments have been fully considered but they 
are generally not persuasive, unless noted otherwise. At page 10 of the Remarks, as 
filed, Applicant argues, inter alia, that there is only one portion in Craft where direct 
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memory access is mentioned. "Claim 1 recites that the first network interface controller 
and the second network interface controller operate under a remote direct memory 
access (RDMA) protocol rather than the direct memory access (DMA)". This argument 
is not persuasive. While it is true that Craft does not explicitly show utilizing RDMA, it 
would have been obvious to do so in combination with AAPA, which states at par. 
[0003] that: "RDMA is a protocol which allows the NIC card to place a data packet in a 
predetermined memory location in the computer systems main memory". In other 
words, RDMA protocol allows for DMA. Thus, the fact that Craft does not recite utilizing 
RDMA protocol for DMA transfer does not preclude NICs of Craft from doing so in 
combination with AAPA. At page 1 1 of the Remarks, as filed, Applicant argues that: 
"Craft describes sending the packet that the INIC 22 cannot process to the INIC device 
driver. By contrast, claim 1 recites sending the message indicating the reception of the 
identifier associated with the memory location in the multiple network interface device 
and the associated data field. While it is not entirely clear from the Office action whether 
it refers to the packet as the message indicating the reception of the identifier or as the 
identifier itself, it appears that nowhere in the reference does Craft teach or suggest this 
limitation". This argument is not persuasive. The Office action was clear in referring to 
the packet as the message indicating the reception of the identifier. The Office action 
also referred to the packet as inherently containing the identifier in the header section of 
the packet. The fact that Craft does not explicitly discuss having an identifier in the 
header section of the packet, and just broadly discusses generating the packet 
summary and comparing a hash of the packet summary with the hash table 
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corresponding to the CCB, should not be taken as an indication that such identifier does 
not exist in the packet of Craft. However, in order to obviate Applicant's concerns 
regarding lack of identifiers in Craft's packets, Oesterreicher reference is used in this 
Office action to explicitly show that a data packet includes an identifier in the header of 
the packet. If Applicant believes that the claimed "message indicating the reception of 
the identifier" is structurally and functionally different from the packet that is sent from 
INIC 22 to the INIC device driver, the claim should be amended to further specify what 
constitutes "the message". At page 12 of the Remarks, as filed, Applicant argues that: 
"the packet described in Craft is different from an identifier associated with a memory 
location in the multiple network interface device". This argument is not persuasive 
because the claim language is lacking specificity as to how the claimed "identifier 
associated with the memory location" is structurally and functionally different from an 
identifier inherently contained in the packet summary of Craft. Also, it is being noted that 
Applicant attempts to argue against the references individually, wherein the rejection of 
claim 1 was based on a combination of references: AAPA and Craft. To this extent, 
AAPA clearly shows an identifier associated with a memory location in the multiple 
network interface device, the identifier contained in the data packet transmitted between 
NICs of two machines. See cited paragraphs of AAPA. Applicant presented no 
arguments pertaining to the combination of AAPA and Craft. At page 13 of the 
Remarks, as filed, Applicant argues that: "in Craft, the ATCP stack 52 processes the 
packet. Further, Craft states that after the packet had been processed, the CCB can be 
handed out to the INIC 22. By contrast, claim 1 recites that the second network interface 
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controller transmits the associated data field to the memory location. Thus, Craft does 
not teach or suggest that the second network interface controller transmits the 
associated data field to the memory location, as recited in claim 1". This argument is 
persuasive. 

As to claim 15, at page 14 of the Remarks, as filed, Applicant argues that: 
"neither the Admitted Art nor Craft teaches or suggests "transmitting the memory 
location associated with the identifier to the second network interface controller, wherein 
the second network interface controller transmits the associated data field to the 
memory location", as recited in claim 15". This argument is persuasive. 

As to claim 8, at page 16 of the Remarks, as filed, Applicant argues that: "Craft 
does not teach or suggest "the identifier generated by the first network interface 
controller and associated with a memory location in the host computer, " as recited in 
claim 8. Further, Craft does not teach or suggest "sending a message to a program 
component indicating the reception of the identifier," as also recited in claim 8". This 
argument is not persuasive for the same reasons as those discussed above with 
respect to claim 1 and which are not repeated here for brevity. At page 17 of the 
Remarks, as filed, Applicant argues that: "Starr does not teach or suggest the identifier 
generated by the first network interface controller and associated with a memory 
location in the host computer recited in claim 1". This argument is not persuasive 
because Applicant attempts to argue against the references individually, wherein the 
rejection of claim 8 was based on a combination of references: AAPA, Craft, Starr, and 
Recio. To this extent, AAPA clearly shows an identifier generated by the first network 
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interface controller and associated with a memory location in the host computer, the 
identifier contained in the data packet transmitted between NICs of two machines. See 
cited paragraphs of AAPA. Applicant presented no arguments pertaining to the 
combination of AAPA, Craft, and Starr. At page 18 of the Remarks, as filed, Applicant 
argues that: "it is not clear why one of skill in the art would invalidate the packet 
summary describing the packet headers when the packet summary does not match a 
CCB when, in such scenario, the headers are processed by the CPU". In their argument 
at this page of the Remarks, Applicant appears to analyze the combination of Craft and 
Starr teachings and the motivation for invalidating the identifier in the packet summary 
of Craft and Starr. However, Applicant completely ignores the teachings of AAPA relied 
on as a primary reference, in particular those pertaining to teaching of identifiers 
generated by the first network interface controller and associated with memory locations 
in multiple network interface device memory. See cited paragraphs of AAPA. Therefore, 
Applicant is reminded that one cannot show nonobviousness by attacking references 
individually where the rejections are based on combination of references. To this extent, 
it would have been obvious to one of ordinary skill in the art at the time of the invention 
to invalidate the identifiers of AAPA, wherein these identifiers are contained in the 
packet summary of Craft and/or Starr teachings, as a result of the combination of these 
references. 

As to any arguments not specifically addressed, they are the same as those 
discussed above. 
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Claim Objections 

4. Claims 1-5, 7-12, 14-19, 21-26, and 28 are objected to because of the following 
informalities: 

see proposed claim amendments attached to this Office action. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1, 5, 7, 15, 19, and 21 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Applicant's Admitted Prior Art (hereinafter AAPA) in view of Craft et 
al. (US Patent No.: 6,687,758 B2) in view of Oesterreicher et al. (US 2004/0006636 A1) 
and in further view of Boucher et al. (2004/0240435 A1 ). 

As to claim 1 , the preamble has been given patentable weight since the claim 
body refers back to the preamble. See "the first network interface controller" and "the 
multiple network interface device" at lines 1-2 of the claim body. 

As to claim 1, AAPA shows a method for transferring control between a first 
network interface controller and at least a second network interface controller in a 
multiple network interface device [as the route the data takes through the Internet 
changes, it is possible that the path chosen from the first machine to the second 
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machine will change in a manner that causes the path between these two machines to 
change from NIC 1 to NIC2 in machine 1] (par. [0005]), the method comprising: 

after the first network interface controller sends an identifier [STag] associated 
with a memory location in the multiple network interface device [the protocol associates 
the memory in the first machine with a handle referred to as a STag. ...a NIC in the first 
machine generates the STag. The STag is then sent to the second machine] (par. 
[0004]), to a second device [the STag is then sent to the second machine] (par. [0004]) 
and the identifier and an associated data field are received by the second network 
interface controller in the multiple network interface device from the second device 
[...the route changes to one which uses NIC 2 before machine 2 sends data to machine 
1 , machine 2 will return data with an STag that is unknown to NIC 2] (par. [0005]). 

AAPA also shows that the second network interface controller has no knowledge 
of the identifier and the associated data field [returned data with an STag is unknown to 
NIC 2] (par. [0005]), and wherein the first network interface controller and the second 
network interface controller operate under a remote direct memory access (RDMA) 
protocol (par. [0003]-[0005]). AAPA further shows that identifiers are generated by the 
first network interface controller and are associated with memory locations in multiple 
network interface device memory [the protocol associates the memory in the first 
machine with a handle referred to as a STag. ...a NIC in the first machine generates the 
STag]. 

AAPA does not show the particular steps recited in the claim for handling 
identifiers generated by one NIC and received by another NIC in the same machine, in 
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cases when control is transferred [paths changed] between a first network interface 
controller and at least a second network interface controller in a multiple network 
interface device. 

In particular, AAPA does not show: 

receiving a message from the second network interface controller in the multiple 
network interface device by a program component of the multiple network interface 
device, the message indicating the reception of the identifier and the associated data 
field from the second device; 

passing the identifier to the program component; 

querying the first network interface controller to supply the program component 
with a list of identifiers; 

identifying, by the program component, that the first network interface controller 
generated the identifier; and 

transmitting the memory location associated with the identifier to the second 
network interface controller, wherein the second network interface controller transmits 
the associated data field to the memory location. 

Craft shows a method for transferring control between a first network interface 
controller and at least a second network interface controller in a multiple network 
interface device (abstract, col. 6 lines 36-42), the method comprising: 

receiving a message [the packet] from the second network interface controller in 
the multiple network interface device [INIC 22 sends the packet that it cannot process 
according to the fast-path connection to the INIC device driver] (col. 6 lines 43-47) by a 
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program component of the multiple network interface device [at least one or more of the 
INIC device driver (64), the ATCP stack (62), and the port aggregation driver (66)] (Fig. 
1), the message indicating the reception of the identifier and the associated data field 
[the packet includes a header portion inherently containing an identifier and a data 
portion] from the second device, wherein the second network interface controller has no 
knowledge of the identifier and the associated data field [INIC 22 sends the packet that 
it cannot process according to the fast-path connection to the INIC device driver, which 
alerts the port aggregation driver (66) of fast-path connection migration] (col. 5 lines 30- 
34); 

passing the identifier to the program component [passing the packet that 
inherently contains the identifier in the header portion of the packet to the INIC device 
driver] (col. 4 lines 30-43; col. 6 lines 43-47); 

querying the first network interface controller to supply the program component 
with a list of identifiers [commanding the INIC 25 to flush the fast-path CCB back to the 
ATCP stack, wherein CCB contains a list of identifiers] (col. 3 line 59 to col. 4 line 9; col. 
6 lines 47-53); 

identifying, by the program component, that the first network interface controller 
generated the identifier [the ATCP stack maintains a list of the CCBs that have been 
offloaded to INICs] (col. 6 lines 47-49); and 

transmitting the memory location associated with the identifier to the second 
network interface controller [commanding the INIC 25 to flush the fast-path CCB back to 
the ATCP stack for processing the packet, and subsequently handing out the CCB to 



Application/Control Number: 1 0/622,21 7 Page 1 1 

Art Unit: 2442 

the INIC 22, which is now associated with the connection] (col. 6 lines 54-57), wherein 
the [program component] transmits the associated data field to the memory location 
(col. 6 lines 53-57). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine the teachings of AAPA and those of Craft, as discussed above, in 
order to provide a method of handling received packets when a packet received by one 
NIC is being handled by other NIC in the same device (col. 6 lines 36-42 in Craft). 

AAPA in view of Craft does not explicitly show a packet containing an identifier in 
a header portion of the packet. 

Oesterreicher shows that a packet contains an identifier in a header portion of 
the packet (par. [0034]; Fig. 5). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the teachings of AAPA in view of Craft by explicitly showing that a 
packet contains an identifier in a header portion of the packet, in order to determine 
which device generated and transmitted the packet and where to place the packet data 
upon reception of the packet. 

AAPA in view of Craft and in further view of Oesterreicher does not show that the 
second network interface controller transmits the associated data field to the memory 
location. 

As discussed above, Craft shows that the program component transmits the 
associated data field to the memory location. 
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Boucher shows transmitting the memory location associated with the identifier to 
the second network interface controller (par. [0018], [0027]-[0029]; Fig. 2), wherein the 
second network interface controller transmits the associated data field to the memory 
location (par. [0030]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the teachings of AAPA in view of Craft and in further view of 
Oesterreicher by having the second network interface controller transmitting the 
associated data field to the memory location (instead of the program component, as 
taught by Craft) in order to offload processing of at least a portion of the packet from the 
program component to the network interface controller (par. [0008] in Boucher). 

As to claims 5 and 19, AAPA in view of Craft, Oesterreicher, and Boucher shows 
that the program component is a computer operating system (par. [0009]; Fig. 1). 

As to claims 7 and 21 , AAPA in view of Craft, Oesterreicher, and Boucher shows 
that the first network interface controller and the second network interface controller 
operate under the RDMA protocol over TCP/IP protocol (par. [0003]-[0005] in AAPA; 
col. 2 lines 54-55, col. 3 lines 62-63 and col. 4 lines 40-42 in Craft). 

As to claim 15, AAPA in view of Craft, Oesterreicher, and Boucher shows a 
computer readable medium having stored therein instructions for performing acts of 
method 1, as discussed above (col. 1 lines 5-10 in Craft). 
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7. Claims 2, 3, 16, and 17 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over AAPA in view of Craft et al., in view of Oesterreicher et al., in view of 
Boucher et al., and in further view of Recio et al. ("An RDMA Protocol Specification 
(Version 1 .0)") - submitted in the IDS dated 06/06/05, Doc. No.: A8. 

As to claims 2 and 1 6, AAPA in view of Craft shows that the state of the CCB is 
updated when packet is processed (col. 6 lines 54-56 in Craft). 

AAPA in view of Craft, Oesterreicher, and Boucher does not show that the 
identifier is invalidated under control of a bit field added to the identifier and the 
associated data field received from the second device. 

Recio shows that the identifier is invalidated under control of a bit field added to 
the identifier and the associated data field received from the second device (page 12 
lines 46-50; page 21). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the method of AAPA in view of Craft, Oesterreicher, and Boucher by 
having the identifier being invalidated under control of a bit field added to the identifier 
and the associated data field received from the second device in order to prevent a 
remote host from subsequent access to the memory location associated with the 
identifier, a well known feature of the RDMA protocol. 

As to claims 3 and 17, AAPA in view of Craft, Oesterreicher, Boucher, and in 
further view of Recio shows that if the identifier has been invalidated, the associated 
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data field is discarded [invalidating STag prevents assess to a memory location 
associated with the identifier] (page 5 lines 15-24; page 12 lines 46-50; page 21 in 
Recio). 

8. Claims 4 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
AAPA in view of Craft et al., Oesterreicher et al., Boucher et al., and in further view of 
Starr et al. (US Patent No.: 6,807,581 B1 ). 

As to claims 4 and 18, AAPA in view of Craft shows that storage (23) may be a 
separate category of the same memory as memory (21) (col. 2 lines 20-24 in Craft). 
AAPA in view of Craft, Oesterreicher, and Boucher does not explicitly show that the 
memory location is random access memory. 

Starr shows that a memory may be composed of random access memory (col. 6 
lines 10-14). 

It would have been obvious to one of ordinary skill in the art to modify the method 
of AAPA in view of Craft, Oesterreicher, and Boucher by having the memory location of 
storage (23) in Craft being a random access memory in order to allow the stored data at 
the storage (23) of Craft to be accessed in any order, regardless of its physical location 
and whether or not it is related to the previous piece of data. 

9. Claims 8-12, 14, 22-26, and 28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over AAPA in view of Craft et al., in view of Oesterreicher et al., in view of 
Starr et al. and in further view of Recio et al. 
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As to claim 8, the preamble has been given patentable weight since the claim 
body refers back to the preamble. See "the first network interface controller" and "the 
host computer" at lines 2-3 of the claim body. 

As to claim 8, AAPA shows a method for transferring control between a first 
network interface controller and at least a second network interface controller in a host 
computer including the first network interface controller and the second network 
interface controller [as the route the data takes through the Internet changes, it is 
possible that the path chosen from the first machine to the second machine will change 
in a manner that causes the path between these two machines to change from NIC 1 to 
NIC2 in machine 1] (par. [0005]), the method comprising: 

receiving an identifier from a remote computer by the at least a second network 
interface controller [...the route changes to one which uses NIC 2 before machine 2 
sends data to machine 1 , machine 2 will return data with an STag that is unknown to 
NIC 2] (par. [0005]), the identifier generated by the first network interface controller and 
associated with a memory location in the host computer [the protocol associates the 
memory in the first machine with a handle referred to as a STag. ...a NIC in the first 
machine generates the STag. The STag is then sent to the second machine] (par. 
[0004]), wherein the second network interface controller has no knowledge of the 
identifier and the associated data field [returned data with an STag is unknown to NIC 2] 
(par. [0005]), and wherein the first network interface controller and the second network 
interface controller operate under a remote direct memory access (RDMA) protocol 
(par. [0003]-[0005]). AAPA further shows that identifiers are generated by the first 
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network interface controller and are associated with memory locations in the host 
computer [the protocol associates the memory in the first machine with a handle 
referred to as a STag. ...a NIC in the first machine generates the STag]. 

AAPA does not show the particular steps recited in the claim for handling 
identifiers generated by one NIC and received by another NIC in the same machine, in 
cases when control is transferred [paths changed] between a first network interface 
controller and at least a second network interface controller in a multiple network 
interface device. 

In particular, AAPA does not show: 

sending a message to a program component indicating the reception of the 
identifier, the program component queries the first network interface controller for a list 
of identifiers; 

passing the identifier received from the remote computer to the program 
component; 

searching the list of identifiers for the identifier; 

when the list of identifiers includes the identifier received from the remote 
computer, receiving a memory location associated with the identifier; and 

when the list of identifiers does not include the identifier received from the remote 
computer, invalidating the identifier received from the remote computer. 

Craft shows a method for transferring control between a first network interface 
controller and at least a second network interface controller in a host computer 
(abstract, col. 6 lines 36-42), the method comprising: 
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sending a message [the packet] to a program component indicating the reception 
of the identifier [INIC 22 sends the packet that it cannot process according to the fast- 
path connection to the INIC device driver, wherein a program component is interpreted 
to include at least one or more of the INIC device driver (64), the ATCP stack (62), and 
the port aggregation driver (66)] (col. 6 lines 43-47; Fig. 1), the program component 
queries the first network interface controller for a list of identifiers [commanding the INIC 
25 to flush the fast-path CCB back to the ATCP stack, wherein CCB contains a list of 
identifiers] (col. 3 line 59 to col. 4 line 9; col. 6 lines 47-53); and 

passing the identifier received from the remote computer to the program 
component [passing the packet that inherently contains the identifier in the header 
portion of the packet to the INIC device driver] (col. 4 lines 30-43; col. 6 lines 43-47). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine the teachings of AAPA and those of Craft, as discussed above, in 
order to provide a method of handling received packets when a packet received by one 
NIC is being handled by other NIC in the same device (col. 6 lines 36-42 in Craft). 

AAPA in view of Craft does not explicitly show a packet containing an identifier in 
a header portion of the packet. 

Oesterreicher shows that a packet contains an identifier in a header portion of 
the packet (par. [0034]; Fig. 5). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the teachings of AAPA in view of Craft by explicitly showing that a 
packet contains an identifier in a header portion of the packet, in order to determine 
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which device generated and transmitted the packet and where to place the packet data 
upon reception of the packet. 

AAPA in view of Craft and in further view of Oesterreicher does not show: 

searching the list of identifiers for the identifier; 

when the list of identifiers includes the identifier received from the remote 
computer, receiving a memory location associated with the identifier; and 

when the list of identifiers does not include the identifier received from the remote 
computer, invalidating the identifier received from the remote computer. 

Starr shows: 

searching the list of identifiers for the identifier [comparing packet summary with 
CCB hashes and CCB cache] (Fig. 3 step (110); col. 9 lines 40-44); 

when the list of identifiers includes the identifier received from the remote 
computer, receiving a memory location associated with the identifier [if the packet 
summary matches a CCB, receiving a memory location according to a file system] (Fig. 
3 steps (120) and (122); col. 9 lines 55-61); and 

when the list of identifiers does not include the identifier received from the remote 
computer [if the packet summary does not match a CCB] (Fig. 3 step (110); col. 9 lines 
44-46), [sending packet to stack for slow-path processing] (Fig. 3 step (112); col. 9 lines 
44-46). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the method of AAPA in view of Craft and in further view of 
Oesterreicher by searching the list of identifiers for the identifier and taking an action in 
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response to searching, as discussed above, in order to determine whether or not 
received packet can be processed by the network interface controller (Fig. 3 of Starr). 

AAPA in view of Craft, Oesterreicher, and in further view of Starr does not show 
invalidating the identifier received from the remote computer when the list of identifiers 
does not include the identifier received from the remote computer. 

Recio shows invalidating the identifier received from the remote computer (page 
5 lines 15-24; page 12 lines 46-50; page 21). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the method of AAPA in view of Craft, Oesterreicher, and in further 
view of Starr by invalidating the identifier received from the remote computer in order to 
prevent a remote host from subsequent access to the memory location associated with 
the identifier once the packet is processed, a well known feature of the RDMA protocol. 

As to claims 9 and 23, AAPA in view of Craft shows that the state of the CCB is 
updated when packet is processed (col. 6 lines 54-56 in Craft). 

AAPA in view of Craft, Oesterreicher, and Starr does not show that the identifier 
is invalidated under control of a bit field added to the identifier and an associated data 
field received from the remote computer. 

Recio shows that the identifier is invalidated under control of a bit field added to 
the identifier and an associated data field received from the remote computer (page 1 2 
lines 46-50; page 21). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the method of AAPA in view of Craft, Oesterreicher, and Starr by 
having the identifier being invalidated under control of a bit field added to the identifier 
and an associated data field received from the remote computer in order to prevent a 
remote host from subsequent access to the memory location associated with the 
identifier, a well known feature of the RDMA protocol. 

As to claims 10 and 24, AAPA in view of Craft, Oesterreicher, Starr, and in 
further view of Recio shows that if the identifier has been invalidated, the associated 
data field is discarded [invalidating STag prevents assess to a memory location 
associated with the identifier] (page 5 lines 15-24; page 12 lines 46-50; page 21 in 
Recio). 

As to claims 1 1 and 25, AAPA in view of Craft shows that storage (23) may be a 
separate category of the same memory as memory (21) (col. 2 lines 20-24 in Craft). 
AAPA in view of Craft and Oesterreicher does not explicitly show that the memory 
location is random access memory. 

Starr shows that a memory may be composed of random access memory (col. 6 
lines 10-14). 

It would have been obvious to one of ordinary skill in the art to modify the method 
of AAPA in view of Craft and Oesterreicher by having the memory location of storage 
(23) in Craft being a random access memory in order to allow the stored data at the 
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storage (23) of Craft to be accessed in any order, regardless of its physical location and 
whether or not it is related to the previous piece of data. 

As to claims 12 and 26, AAPA in view of Craft and in further view of 
Oesterreicher shows all the elements except for the program component being a 
computer operating system. 

Starr shows a program component being a computer operating system [file 
system (23)] (col. 6 lines 15-39). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the method of AAPA in view of Craft and Oesterreicher by having 
the program component being a computer operating system in order to utilize a high 
level software entity that contains general knowledge of the organization of information 
on storage units and file caches, and provides algorithms that implement the properties 
and performance of the storage architecture (col. 6 lines 15-19 in Starr). 

As to claims 14 and 28, AAPA in view of Craft shows that the first network 
interface controller and the second network interface controller operate under the 
RDMA protocol over TCP/IP protocol (par. [0003]-[0005] in AAPA; col. 2 lines 54-55, 
col. 3 lines 62-63 and col. 4 lines 40-42 in Craft). 
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As to claim 22, AAPA in view of Craft, Oesterreicher, Starr, and in further view of 
Recio shows a computer readable medium having stored therein instructions for 
performing acts of method 8, as discussed above (col. 1 lines 5-10 in Craft). 

Conclusion 

1 0. Applicant's amendment necessitated the new grounds of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to OLEG SURVILLO whose telephone number is 
(571)272-9691 . The examiner can normally be reached on M-Th 8:30am - 6:00pm; F 
8:30am - 5:00pm EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Andrew Caldwell can be reached on 571-272-3868. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Examiner: Oleg Survillo /Andrew Caldwell/ 

Supervisory Patent Examiner, Art 
Phone: 571 -272-9691 Unit 2442 



